Data communication networks may include various computers, servers, nodes, routers, switches, bridges, hubs, proxies, and other network devices coupled to and configured to pass data to one another. These devices will be referred to herein as “network elements.” Data is communicated through the data communication network by passing protocol data units, such as Internet Protocol packets, Ethernet frames, data cells, segments, or other logical associations of bits/bytes of data, between the network elements by utilizing one or more communication links between the network elements. A particular protocol data unit may be handled by multiple network elements and cross multiple communication links as it travels between its source and its destination over the network.
The various network elements on the communication network communicate with each other using predefined sets of rules, referred to herein as protocols. Different protocols are used to govern different aspects of the communication, such as how signals should be formed for transmission between network elements, various aspects of what the protocol data units should look like, how protocol data units should be handled or routed through the network by the network elements, and how information associated with routing information should be exchanged between the network elements.
Ethernet is a well known networking protocol that has been defined by the Institute of Electrical and Electronics Engineers (IEEE) as standards 802.1 and 802.3. Conventionally, Ethernet has been used to implement networks in enterprises such as businesses and campuses, and other technologies have been used to transport network traffic over longer distances. As the Ethernet standards have evolved over time, Ethernet has become more viable as a long distance transport technology as well.
FIG. 1 shows several fields that have been added to the Ethernet standard over time. As shown in FIG. 1, the original Ethernet frame format specified by IEEE 802.1 includes a source address (C-SA) and a destination address (C-DA). IEEE 802.1Q added a Customer VLAN tag (C-Tag) which includes an Ethertype, Tag Control Information (TCI) information, and customer VLAN ID (C-VID). IEEE 802.1ad added a provider VLAN tag (S-Tag), which also includes an Ethertype, TCI information, and subscriber VLAN ID. The C-Tag allows the customer to specify a VLAN, while the S-Tag allows the service provider to specify a VLAN on the service provider's network for the frame. These tags also allow the customer and subscriber to specify other aspects which are not relevant to an understanding of the contribution disclosed herein. When a network is implemented using 802.1ad it may be referred to as Q in Q encapsulation or Provider Bridging (PB). A domain implemented using this Ethernet standard will be referred to as a Provider Bridging (PB) domain.
The Ethernet standard has evolved to also allow for a second encapsulation process to take place as specified in IEEE 802.1ah. Specifically, an ingress network element to a service provider's network may encapsulate the original Ethernet frame with an outer MAC header including a destination address on the service provider's network (B-DA), a source address on the service provider's network (B-SA), a VLAN ID (B-VID) and a service instance tag (I-SID). The combination of the customer MAC addresses (C-SA and C-DA) and the I-SID are commonly referred to as the I-Tag. A domain implemented using this Ethernet standard will be referred to as a Provider Backbone Bridging (PBB) domain.
802.1Q, 802.1ad, and 802.1ah all use one or more spanning tree instances in the control plane to determine which links should be active and which should be blocked to prevent the formation of loops. An Ethernet network domain that implements one or more spanning trees on the control plane will be referred to herein as a spanning tree controlled Ethernet network domain.
Since a spanning tree requires all data to flow on particular selected links on the network, the network links that are part of the spanning tree may experience congestion. IEEE 802.1Qay was developed to allow traffic engineered paths to be defined on the network so that traffic could be forwarded over links not forming part of the spanning tree. IEEE 802.1Qay specifies a way for network elements on an Ethernet network domain to switch traffic based on the B-DA and B-VID rather than just forwarding the traffic according to the B-DA. The header of the frames forwarded on an Ethernet network established using this technology is not changed, but the manner in which the header information is used is changed, to allow forwarding to take place in a different manner. A network domain that forwards traffic using this forwarding paradigm will be referred to as Provider Backbone Bridging-Traffic Engineering (PBB-TE or PBT) network. PBT networks allow traffic engineered paths (trunks) to be established so that traffic can follow specified paths through the network rather than being required to follow the links that have been selected to be part of the spanning tree. The spanning tree is still used to forward control frames, however.
Network nodes may be logically or physically arranged many different ways. One common way to arrange or interconnect network elements is to interconnect them in a ring, for example as shown in FIG. 2. Closed loops, such as the loop shown in FIG. 2 may exist in isolation or may exist as a logical ring within a larger mesh network. The techniques described herein may be used wherever a set of Ethernet nodes is interconnected, logically or physically, to construct a closed loop network topology. For example, in a communication network having a mesh configuration, it is possible to form a logical ring by selecting nodes 12 from the mesh that interconnect to form a closed loop network topology.
In the example shown in FIG. 2, the ring 10 includes nodes 12, which are interconnected by links 14. In the example shown in FIG. 2, each node has a pair of 802.3 MAC interfaces 16 and an 802.1 bridge relay 18. 802.3 is another protocol established by the IEEE to define the Ethernet link layer. A control entity 20 is used to allow the network elements to exchange forwarding information and other control information, and is used by the network element to control how the data plane handles the data on the network. For example, the control entity enables the node to participate in the spanning tree. A switch may have more than one bridge relay and control entity. In this type of switch, the bridge relay/control entity that handles client MAC addresses is commonly referred to as the C-Component or “C-COMP”, and the bridge relay/control entity that handles provider MAC addresses and adds the B-header is commonly referred to as the B-Component or “B-Comp”.
One protocol designed to be used in Ethernet rings, such as the ring of FIG. 2, is defined as ITU-T SG15/Q9, G.8032. This protocol specifies the protection and recovery switching protocol for use on an Ethernet ring network. Briefly, when Ethernet nodes are interconnected in a closed loop architecture, the nodes may be allowed to collectively run a separate control plane to control how data is passed between the nodes on the ring. The control plane on the closed loop selects one of the nodes to be a root node to provide for blocking of traffic flowing on the ring. This prevents traffic from endlessly looping on the ring. Additionally, the control plane provides for failure detection on the closed loop, notification of the failure to the nodes on the closed loop, and how connectivity can be restored to enable the closed loop to recover from failure. One aspect of the control protocol is that, upon failure in the closed loop, a fault indication message will be transmitted on the ring. The fault indication message, amongst other things, causes the bridging nodes on the ring to flush their forwarding databases associated with the ring, so that the nodes can re-learn MAC addresses on the ring.
One Ethernet ring solution that uses the underlying G.8032 protection protocol is described in greater detail in U.S. patent application Ser. No. 12/027,942, entitled Method And Apparatus For Controlling A Set Of Ethernet Nodes Interconnected To Form One Or More Closed Loops, filed Feb. 7, 2008. As extensions to this basic ring control protocol, U.S. patent application Ser. No. 12/344,355 entitled Interworking An Ethernet Ring Network With a Spanning Tree Controlled Ethernet Network, filed on Dec. 26, 2008, describes a way for an Ethernet Ring Network to be dual homed to an Ethernet network running a spanning tree in the control plane. Likewise, U.S. patent application Ser. No. 12/344,362, entitled Interworking An Ethernet Ring Network With a an Ethernet Network with Traffic Engineered Trunks, filed on Dec. 26, 2008, describes a way for an Ethernet Ring Network to be dual homed with a network implementing traffic engineered trunks, i.e. a network implemented using 802.1Qay. Each of these patents is incorporated herein by reference.
U.S. patent application Ser. No. 12/027,942, filed Feb. 7, 2008, describes a way in which both meshed connectivity and hub-and-spoke connectivity may be implemented on the ring network. In meshed connectivity, each node may communicate directly with each other node on the ring. In hub-and-spoke connectivity, communication between the nodes is restricted such that the hub node can talk to each of the spoke nodes, and each of the spoke nodes can talk to the hub node, but the spoke nodes cannot talk directly with each other. This type of connectivity is advantageous for applications such as Internet access, video distribution, DLSAM backhaul, e-line services, etc.
In the previous hub-and-spoke solution, one RVID value was used by all spoke nodes to transmit frames to the hub, and a second RVID value was used by the hub to transmit frames to the spokes. Spoke nodes would only process (e.g., remove) data frames from the ring if they contained an RVID value indicating they were transmitted by the hub node, and the hub node would process data frames containing an RVID value indicating that they were transmitted by one of the spokes. Unfortunately, although this enabled hub-and-spoke connectivity to be implemented, it required the hub node to perform MAC learning on routes extending through each of the spokes, which caused scalability issues at the hub node. Accordingly, it would be advantageous to provide a more scalable way for hub-and-spoke connectivity to be implemented on an Ethernet ring network.